Distributed process control systems, like those used in chemical, petroleum or other process plants, typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital, or combined analog/digital buses, or via a wireless communication link or network. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and generally perform physical or process control functions such as opening or closing valves, measuring process parameters, etc., to control one or more processes executing within the process plant or system. Smart field devices, such as the field devices conforming to the well-known FOUNDATION® Fieldbus protocol, may also perform control calculations, alarming functions, and other control functions commonly implemented within a process controller. The process controllers, which are also typically located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices and execute a controller application that runs, for example, different control modules which make process control decisions, generate control signals based on the received information, and coordinate with the control modules or blocks being performed in the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over the communication lines or links to the field devices to thereby control the operation of at least a portion of the process plant or system.
Information from the field devices and the controller is usually made available over a data highway to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized administrative computing devices that are typically placed in control rooms or at other locations away from the harsher plant environment. Each of these hardware devices typically is centralized across the process plant or across a portion of the process plant. These hardware devices run or execute various different applications that may, for example, enable an operator to perform functions with respect to controlling a process and/or operating the process plant, such as changing settings of the process control routines, modifying the operation of the control modules within the controllers or the field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc. The data highway utilized by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.
As an example, the DeltaV™ control system, sold by Emerson Process Management, includes multiple different applications stored within and executed by different devices located at diverse or distributed places within a process plant. A configuration application, which resides in one or more workstations or computing devices, enables users to create or change process control modules and download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks, which are objects in an object oriented programming protocol that perform functions within the control scheme based on inputs thereto and that provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration designer to create or change operator interfaces which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality. The viewing applications, which may be executed on one or more operator workstations (or on one or more remote computing devices in communicative connection with the operator workstations and the data highway), receive data from the controller application via the data highway and display this data to process control system designers, operators, or users using the user interfaces, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway while a configuration database application may execute in a still further computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.
In any event, as will be evident from the above discussion, there are many supporting applications and systems that are implemented in or across the various computer devices within a process plant and process plant control system, such as various hardware and software diagnostic applications, control applications, configuration applications, computer operating system software and firmware applications, communication devices, network security devices, etc. Each of these various applications or components of a process plant control system may collect, generate, and store various different types of data in various different formats and at various different locations or databases within the plant. The applications may, for example, store basic or underlying computer settings or configuration settings, such as those associated with various computer hardware devices within the plant, and operating system software or firmware parameters used in various computers within the plant. Additionally, the applications may store basic communication and communication network settings, configuration data, or other data related to the manner in which electronic communications are set up in the plant using various different types of communication hardware and software implemented according different communication protocols used within the plant. Still further, other applications may generate and store data pertaining to the manner in which various process control software and process plant hardware and software diagnostic applications are set up or configured within the plant to perform various control, display, communication, calibration, diagnostic, security, and other actions within the plant. Needless to say, there can be very many applications or systems present within and executed within a plant environment, and each of these applications or systems may have various different types of data, configuration settings, etc. associated therewith.
Moreover, some newer process plant systems may include “big data” machines that collect some or all of the data generated within or about a process plant and generated by the various systems within the plant. “Big data” generally refers to a collection of one or more data sets that are so large or complex that traditional database management tools and/or data processing applications (e.g., relational databases and desktop statistic packages) are not able to manage the data sets within a tolerable amount of time. Typically, applications that use big data are transactional and end-user directed or focused. For example, web search engines, social media applications, marketing applications, and retail applications may use and manipulate big data. Big data may be supported by a distributed database that allows the parallel processing capability of modern multi-process, multi-core servers to be fully utilized. As noted above, there has been some recent developments towards incorporating big data or big data machines within a process control system for the purpose of archiving process control data at a level that has not been available in the past. However, there is currently no or only very limited ability to analyze or use this data, as collected from a process plant or a process, to perform comprehensive or systematic analysis of the plant operation, to be able to detect trends, perform predictive analysis, detect abnormalities within the plant operation, retune or reconfigure the plant to operate more economically, etc.
Thus, as will be understood, while various different process plant or process control systems associated with different process plants or plant locations may use the same basic computer hardware, communications networks, process control and diagnostic software systems, and other supporting applications, each plant may be set up and configured differently during operation, thereby making, in essence, each plant or even sub-portions of the same plant, a unique computer system that is configured and operated in a unique manner. There are many, many factors that go into setting up or configuring a plant control and communication network, including control settings, configuration settings, hardware connections, computer operating system software and versions thereof, computer hardware and software updates that may or may not have been installed in the plant, identities of and locations of databases and other hardware within the plant, firewall or other security settings, etc. Moreover, plant operators may make mistakes in setting up or configuring the plant hardware and software systems. In most cases plant operators, and in some cases even plant information technology (IT) personnel, do not completely understand the underlying configuration and structure of a plant network (including, for example, plant computer and communication networks), and thus these individuals are generally unable to detect the source of all errors or problems that may occur within a plant system, much less to fix the errors when running the plant networks or systems. To assist plant personnel in maintaining and operating these complex process control systems within a plant, process control system software providers generally provide technical assistance to users of the process control system software to assist the users (customers) in trouble shooting computer and network issues and in applying fixes for detected problems.
However, troubleshooting customers' issues may be a time consuming task, as this troubleshooting usually involves collecting diagnostic data from the customer computer systems and then analyzing the collected data in a manual manner to detect abnormalities, improper settings, etc. Some issues are difficult to troubleshoot, which may involve escalation of the issue up to technology experts who actually dig into the source code of the control and network software to determine the root cause of the issue. On the other hand, some issues are very easy to troubleshoot because they are known issues that have occurred in different customers' systems in the past, and these information pertaining to these issues may have been documented and stored in a known location or manner for use in later troubleshooting and problem solving. Generally, in some systems, the detected issues and the solutions thereto are stored in a Knowledge Base Article (KBA) which may then be accessed by IT personnel who run across the same or similar issue in a customer's system.
Generally, the process of troubleshooting and providing a solution to a customer's issue using current troubleshooting support systems involves collecting data from the customer's site as specified by a local engineer, a product engineer (PE) or someone else at a global service center (GSC), and then having the global service center (GSC) personnel (such as a product engineer or a local engineer) review the collected data to determine if the customer's symptoms/issues are known and listed in a previously stored KBA. For experienced or senior engineers, this process can be a straight-forward task because these experienced engineers have performed this analysis many times. For example, the experienced engineers may know exactly which log file (of a number of data files collected from a customer site) to open, what keywords/tokens to look for in the log files, etc., in order to solve or detect the source of a problem or issue.
On contrary, however, newly hired or junior level engineers may require a longer time to analyze data to assist in correcting issues, even if the issues are known issues, and especially if the issues are new ones (i.e., ones not associated with any stored KBAs). This manual approach is also not scalable, as the number of experienced or senior engineers is not always proportional to the number of new or junior engineers.
To make things easier, a more automated process has been developed to assist in detecting and solving customer site support issues. In particular, this automated process applies previously created analytic rules to the data files collected from a customer's site, and uses these rules to generate analytic results which point to or identify one or more KBAs which may assist in understanding or solving a problem. These rules may be run automatically on any new set of customer data to assist the engineers at the support center in diagnosing network and process control system issues at a customer site. However, this automated process is an ever-green process that requires adding more analytic rules to solve more issues. Unfortunately, generating new analytic rules within this automated process generally requires the involvement of a development team that understands how to create and to code the new analytic rules in a manner that can be used by the analysis engine associated with the automated process.
In particular, a current analytic support system in use involves an engineer at the service center submitting diagnostic data collected from a customer plant to one or more analytic engines, which then analyze the collected data by applying a set of finite analytic rules to the data, looking for known issues. After running the analytic rules, the analytic engine produces a list of analytic results which indicates any issues found, based on the analytic rules used in the analytic engine, and provides one or more possible resolutions to the problem, which resolutions are specified by the analytic rules run within the analytic engine. However, in this system, only a developer can add more analytic rules to the analytic engine. In particular, to develop the analytic rules, a support system engineer writes down the manual troubleshooting steps that she or he usually performs, and then submits this log in writing to a development team. A rule developer then uses these manual troubleshooting steps to write computer code that automates the manual troubleshooting steps as performed by the local engineer to form one or more new analytic rules. The developer then tests and publishes the new analytic rules to the analytic engine, which thereafter uses these new rules to analyze customer data. However, the new rules must be manually created by a highly specialized or expert developer who has knowledge of the analytic engine and who is able to program new rules in the language and format that will work within the analytic engine. Moreover, the process of developing new rules is time consuming, and can result in a significant delay between the time when a particular issue occurs (for the first time) and the time at which a rule that detects and provides a solution for that issue is created and provided to the analytic engine to detect the same issue in other customer locations at later times.